REMARKS 



I. 35 U.S.C. 8 102(b) Rejections 

Independent Claims 3, 7, 15, 37, 39, and 88 were rejected under 35 U.S.C. § 102(b) as 
being anticipated by a WIPO patent document corresponding to U.S. Patent No. 6,157,948 to 
Inoue et al. Because Inoue et al. does not teach each and every element recited in the 
independent claims. Applicants respectfully request reconsideration and withdrawal of the 
rejections of those claims and their dependent claims. 

A. Independent Claims 3, 7, 15. and 88 

Independent Claims 3, 7, 15, and 88 each recite that the host device requires the program 
code stored in a solid-state memory device to read data stored in the solid-state memory device. 

Inoue et al. does not teach this element. 

In the Office Action, it was asserted that Inoue et al. teaches an audio-video player, which 
presumably corresponds to the recited host device, and a storage unit storing program code and 
additional program segments. According to the Office Action, the program code in the storage 
unit is used to fetch the additional program segments in the storage unit and provide them to the 
audio-video player. However, the fact that the program code is written to fetch the program 
segments in the storage unit does not mean that the audio-video player cannot otherwise read the 
program segments in the storage unit. The audio-video player, on its own, may not be able to 
perform the exact function performed by the program code, but there is no cited teaching that the 
audio-video player requites the program code to read the program segments. Accordingly, Inoue 
et al. is not sufficient to anticipate independent Claims 3, 5, 7, and 88. As such, Applicants 
respectfully request reconsideration and withdrawal of the rejections of those claims and their 
dependent claims. 



B. Independent Claims 37 and 39 

Independent Claim 37 recites using program code stored in a solid-state memory device 
to store data only in the solid-state memory device, and independent Claim 39 recites a solid- 
state memory device comprising program code operative to enable a host device to store data 
only in a certain portion of the solid-state memory device. Inoue et al. does not teach these 
elements. 

In the Office Action, it was asserted that Inoue et al. teaches an audio-video player and a 
storage unit storing program code. According to the Office Action, the program code in the 
storage unit can be used by the audio-video player to write code in the storage unit. Even under 
this characterization of Inoue et al., Inoue et al. does not teach that the program code enables the 
audio-video player to store data only in the storage unit. The fact that the program code in Inoue 
et al. allows the audio-video player to store data in the storage unit does not mean that the 
program code enables the audio-video player to store data only in the storage unit. In fact, Inoue 
et al. teaches the opposite. As pointed out by the Examiner, col. 37, lines 12-26 describe 
different forms of the storage medium. One of those forms is a read only memory (ROM). If 
program code were written in a ROM, the program code would necessarily need to write data in a 
device other than the ROM (because it is read only). Accordingly, the program code necessarily 
is not operative to store data only in the memory device that contains the program code, as 
recited in independent Claims 37 and 39. Thus, Inoue et al. is not sufficient to anticipate 
independent Claims 37 and 39, and the rejections of those claims and their dependent claims 
should be withdrawn. 



3 



n. 35 U.S.C. S 103(a) Rejections 

Independent Claims 16, 21, 24, 28, 33, 89, 90, and 91 were rejected under 35 U.S.C. § 
103(a) as being unpatenable in view of the proposed combination of Inoue et al., U.S. Patent No. 
6,141,756 to Bright et al., and U.S. Patent No. 6,308,317 to Wilkinson et al. Applicants 
respectfully request reconsideration and withdrawal of these rejections for at least the reasons set 

forth below. 

A. Independent Claims 16 and 89 

Independent Claims 16 and 18 each recite that the host device requires the program code 
stored in a solid-state memory device to read data stored in the solid-state memory device. 
Inoue et al. was relied upon for this teaching. However, as discussed above, Inoue et al. does not 
teach this element. 

In the Office Action, it was asserted that Inoue et al. teaches an audio-video player and a 
storage unit storing program code and additional program segments. According to the Office 
Action, the program code in the storage unit is used to fetch the additional program segments in 
the storage unit and provide them to the audio-video player. However, the fact that the program 
code is written to fetch the program segments in the storage unit does not mean that the audio- 
video player cannot otherwise read the program segments in the storage unit. The audio-video 
player, on its own, may not be able to perform the exact function performed by the program code, 
but there is no cited teaching that the audio-video player requires the program code to read the 
program segments. 

For at least this reason, the proposed combination fails to render independent Claims 16 
and 89 and their dependent claims unpatentable. 
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R. Independent Claims 21. 24^ 28. 33. 90. and 91 

Independent Claims 21, 24, 28, 33, 90, and 91 each recite an element relating to a 
memory device storing encrypted program code and an identifier. A host device can decrypt the 
encrypted program code using the identifier. In this way, the program code is "tied" to the 
memory device. That is, the program code can be decrypted on any host device as long as the 
program code is coming from the memory device (because the memory device provides the 
identifier needed to decrypt the program code along with the program code). If, however, the 
program code is copied to a different memory device, which would not have the same identifier, 
the host device would not be able to decrypt the program code because the different memory 
device would only provide the program code and not the identifier needed to decrypt the program 
code. The Office Action admitted that this element was not shown in Inoue et al. and relied upon 
Bright et al. and Wilkinson et al. in an attempt to cure this deficiency. However, one skilled in 
the art would not have been motivated to make the proposed combination because it would 
change the basic operating principle of Bright et al. 

Bright et al. is concerned about a processor executing an untrusted program from an 
external source. To ensure that only trusted programs are executed. Bright et al. describes a 
system in which trusted programs are encrypted with a key that is embedded in the processor. 
Since only trusted sources will have knowledge of the key, the processor can be assured that any 
program that is decrypted by the processor's key is from a trusted source and, therefore, safe to 
execute. However, Bright et al. stores its identifier in the processor and not in the memory 
device that provides the program code, as recited in independent Claims 21, 24, 28, 33, 90, and 
91. Wilkinson et al. purportedly teaches encrypting an application on a card with an identifier 
stored on the card. However, one skilled in the art would not have been motivated to combine 
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Bright et al. and Wilkinson et al. because moving the key from the processor to the memory 
device would change the basic operating principle of Bright et al. 

As discussed above, by using a key embedded in the processor, the processor in Bright et 
al. knows that any program that can be decrypted using the key is from a trusted source and is, 
therefore, safe to execute. Under the proposed combination, the key would be moved from the 
processor to the memory device that provides the program. This eliminates the processor's 
ability to "check" the trustworthiness of the program and creates a "fox guarding the hen house" 
situation by delegating security (the key) to the very entity that Bright et al. is trying to guard 
against (the provider of the program code). Instead of the processor knowing that a program is 
safe because it is able to unlocked the program with the processor's key, the processor would 
have no assurances that the provided program is safe. This reintroduces the very problem that 

Bright et al. sought to overcome. 

Because the proposed combination would change the basic operating principle of Bright 
et al., one skilled in the art would not have been motivated to make the proposed combination. 
Accordingly, Applicants respectfully request reconsideration and withdrawal of the rejections of 
independent Claims 15, 33, 37, 39, 88, and 91 and their dependent claims. 
III. Conclusion 

In view of the foregoing remarks, Applicants respectfully submit that this application is in 
condition for allowance. Reconsideration is respectfully submitted. It should be noted that while 
only some elements of the independent claims were discussed above, other elements of the 
independent claims, as well as the dependent claims, provide additional grounds of patentability. 
Applicants reserve the right to present these additional grounds at a later time, if necessary. 
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I 



If there-are any questions concerning this Response, the Examiner is invited to contact the 
undersigned attorney at (312) 321-4719. 



BRINKS HOFER 

GILSON & LIONE 
P.O. Box 10395 
Chicago, Illinois 60610 
(312) 321-4719 



Dated: October 3 1 , 2007 




Reg. No. 41,9^0 
Attorney for Applicants 



7 



